URLs or universal resource locators are used to access resources which can be provided over a communications network such as the Internet. URLs are simply formatted strings that identify particular resources. Typically, a user or client will send a URL to a network server that will respond by sending the requested resource, such as a web page, back to the client. URLs that are provided by a client sometimes have a different, simpler form than those that are used by the server and/or web-site rendering engine that provides the requested resource. For example, a client-provided URL might take the following form: http://<hostname>/<Abs Path>, where the “hostname” is a network host domain name or address, and “Abs Path” is the location of the resource requested. The location could be a simple directory path to a .htm file, or a list of parameters that the web site rendering engine can act upon to generate HTML-formatted content. Yet, the URL which is used by the web-site rendering engine is often much more complex in form than the client-provided URL. For example, the form used by the rendering engine might take the following form: <Abs Path>/script/foo.dll/<identifier>. The URL form that is used by different rendering engines can really take many forms, and contain the required details that are necessary for the rendering engine to find or generate the requested resource. It is desirable for this more complex URL form to be transparent to the client. This way, the client need only see and/or provide the more simple “user-friendly” URL to the server or web-site rendering engine. Additionally, the underlying complex URL may in fact change over time, while it is desirable for the external form of the URL to remain unchanged so as to not affect customers of the service.
Against this backdrop, a need has arisen for a solution to the problem of translating or mapping the simpler, user-friendly URLs into the more complex URLs needed by a rendering engine. Attempts in the past have failed to provide truly flexible, convenient, and dynamic solutions. For example, one past solution was a so-called hard-coded approach which simply provided fixed software code with built-in logic to handle the desired mappings. One way of doing this is to provide a series of IF, THEN statements or a CASE statement to handle the mapping. Problems associated with this approach include that the set of mappings which is supported is fixed, and any changes, such as adding new mapping statements, or modifying existing mapping statements, requires the code to be modified or rewritten. This, in turn, results in a large turn around time which is highly undesirable. In addition, the web service must typically be stopped and restarted which is undesirable and unacceptable for large web-sites that see a large amount of traffic. Moreover, building the rule-mapping logic into the code makes it difficult to have any hierarchical organization of the rules, or to support reverse mapping of the rules. So, in short, the solutions which have been proposed and implemented to date do not provide the flexibility, convenience, and dynamic performance which is so desirable, and in fact, necessary in the current operating environment.